The invention relates to a method for running Push-Button Configuration sessions within a heterogeneous network, a first network node device for running Push-Button Configuration sessions within a heterogeneous network, a second network node device for running Push-Button Configuration sessions within a heterogeneous network, a computer readable storage media executable by a processor to run Push-Button Configuration sessions within a heterogeneous network and a heterogeneous network for running Push-Button Configuration sessions.
The current data-centric use of networks (Internet access, media streaming) is increasingly extended towards home control functionality (home automation for climate control, lighting, burglar alarm, home energy network). Such home networks use according to FIG. 1 for instance various communication network technologies like Ethernet (IEEE 802.3), WLAN/WiFi (IEEE 802.11), and Power Line Communication (PLC; IEEE 1901). For this reason they are heterogeneous. The standard IEEE P1905.1, which is currently under development, defines a home network standard supporting different network technologies by a specified “IEEE P1905.1”-Abstraction Layer.
FIG. 2 shows the design of the abstraction layer based on the ISO/OSI-Reference Model with a management and data plane. The abstraction layer is embedded in an IEEE P1905.1-Architecture above a Media Access Control (MAC)-layer and a Physical layer as part of a “Network Node Device” NND within the heterogeneous network. Thus, the network node device NND uses the cited technologies like Ethernet (IEEE 802.3), WLAN/WiFi (IEEE 802.11), and Power Line Communication (PLC; IEEE 1901) and additionally a technology according to the specification of the Multimedia over Coax Alliance (MoCA) via corresponding interfaces according to FIG. 2. It is not compulsory or mandatory for a typical network node device to support all cited communication technologies. It is possible that the network node device NND supports only one or two of the cited technologies or completely other network technologies. Thus the network node device NND supports at least one network technology.
At least one goal of the IEEE P1905.1 standardization activities is the security mechanism during a setup or registration of a new device, called an “enrollee”, which wants to join the heterogeneous network. The security mechanism is needed to protect the home network from external attacks. Such security mechanisms have to be configured with a security credential (password, passphrase, cryptographic key) that is burdensome to set-up manually.
Therefore there is a need for easy user-friendly setup of a security credential for a network supporting different communication network technologies such as using a push button configuration method.
The standard IEEE P1905.1 is currently under development. Section 9 of the current draft version (1905_1-11-0067-00-WGDC-proposal-for-cdhn-standard.doc) defines rudimentary signalling procedures for an automatic cross-technology security setup. However, important functionality is missing so far, especially for dealing with so-called overlapping sessions.
The closest technical solution is defined in Wi-Fi Protected Setup (WPS) (WPS Specification 1.0). Described is a monitoring for simultaneous push-button configurations (PBC). If a session overlap is detected, the push button configuration fails.
More detailed information follows below:
There exist different technologies for user-friendly security set-up specific for a single technology.
Bluetooth defines Pairing procedures (legacy and secure simple pairing) to set-up a secret key between two Bluetooth devices (see: http://en.wikipedia.org/wiki/Bluetooth#Pairing.2FBonding).
Wi-Fi Protected Setup (WPS) defined by the Wi-Fi Alliance is the de-facto standard for WLAN security setup (see: http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup and: http://www.wi-fi.org/wifi-protected-setup). As part of the Push Button Configuration (PBC) protocol run, a check for an overlapping session is performed. If an overlapping PBC session is detected, the set-up procedure is aborted. The simultaneous announcement by a single device on two frequency bands is not considered as session overlap.
According to the WPS Specification 1.0 WPS Specification 1.0 in Section 10.3, page 77 the following is known:
The button press or equivalent trigger event on the Enrollee causes it to actively search for a Registrar in PBC mode. However, the Enrollee MUST not proceed immediately with the Registration Protocol when it first discovers a Registrar. Instead, the Enrollee must complete a scan of all IEEE 802.11 channels that it supports to discover, if any other nearby Registrars are in a Push Button Configuration (PBC) mode. The Enrollee performs this scan by sending out probe requests with a Device Password ID indicating that the Enrollee is in PBC mode and receiving probe responses indicating a Selected Registrar with a PBC Device Password ID. During this scan, the Enrollee must abort its connection attempt and signal a “session overlap” error to the user if it discovers more than one Registrar in PBC mode. If a session overlap error occurs, the user should be advised through the Enrollee or the Registrar user interface (UI) or product literature to wait some period of time before trying again.
Note:
In the case of a dual-band access point (AP) and a dual-band station, the station may discover more than one registrar in the PBC mode. If the dual-band station does discover more than one registrar in the PBC mode, one each RF band, and the Universal Unique IDentifier (UUID) in the beacon and probe-response are the same for all RF bands, then the station shall not consider this to be a session overlap.
FIG. 3 shows the message chart (WPS PBC Message Exchange known from Error! Reference source not found.) for push-button configuration involving the new device to be registered (called Enrollee), an access point (AP) being in direct communication with the Enrollee and a Registrar that actually performs the registration (i.e. it establishes a credential with the Enrollee). The registration messages (M1 . . . M8) are embedded in EAP messages that are forwarded by the AP.
Before the actual registration starts, a monitoring is performed to detect an overlapping PBC session: After Button press B_E by the Enrollee, the Enrollee sends probe request messages indicating that it is in a PBC mode. The AP forwards the information to the registrar. After a button press B_R or an equivalent trigger event on the registrar, the registrar checks whether more than one Enrollee PBC probe request has been received by the Registrar within 120 seconds prior to the PBC button press on the Registrar (PBC Monitor Time). If more than one Enrollee PBC probe request has been received within the Monitor Time interval, the Registrar signals a session overlap error and refuses to enter PBC mode or perform a PBC-based Registration Protocol exchange. In general, the two buttons B_E and B_R may be pressed in any order as long as both are pressed within a 120 sec time interval.
Note:
The message SetSelectedRegistrar notifies the AP that the registrar is currently in PBC mode. So this message causes the change in behaviour of the AP that it answers with a PBC probe response message (positive answer “PBC” instead of negative answer “!PBC”).
This technical solution has as main drawback that it is suitable only for a limited usage scenario:
Only a single technology (WLAN) is supported.
The case of multiple access points (nodes) belonging to the same (home) network and each of them being potentially used for the PBC is not considered.
“Appendix A” in WPS Specification 1.0 WPS Specification 1.0 in Section 13 describes a setup in which multiple registrars are supported, so that the user (Enrollee) has to select with which registrar it wants to register.
The current draft version of the standard IEEE P1905.1 1905_1-11-0067-00-WGDC-proposal-for-cdhn-standard.doc includes the following description for the push button configuration in section 9.2.2 (P1905.1 PBC (Push Button Configuration) Setup Method):
The IEEE P1905.1 PBC method works between two IEEE P1905.1 devices on the same IEEE P1905.1 Network, even when these two devices do not include an IEEE P1905.1 interface of the same underlying network technology if they are bridged by a device with the same underlying network technologies.
An example of the IEEE P1905.1 PBC method is illustrated in FIG. 4 (Example of IEEE P1905.1 Push Button Event Notification and IEEE P1905.1 Push Button Configuration).
In section 9.2.2.1 “P1905.1 Push Button Event Handling” of the current IEEE P1905.1 Draft Version “1905_1-11-0067-00-WGDC-proposal-for-cdhn-standard.doc” it is said:
The handling of IEEE P1905.1 Management messages in IEEE P1905.1 Devices is a common behaviour (powering up the interfaces and generating a sequential message ID across all message types from the device).
If the physical or logical PBC button is pushed on an IEEE P1905.1 Device and if an underlying network specific Push Button Configuration sequence is not currently being performed on any of the network interfaces of this IEEE P1905.1 Device, then a Push Button Event is triggered on an IEEE P1905.1 Device
If a Push Button event is triggered on an IEEE P1905.1 Device, then the Application Layer Management Entity (ALME) shall:
Generate an eventID for this Push Button Event
Send a Push_Button_Event Notification IEEE P1905.1 Multicast message over its Authenticated IEEE P1905.1 Links using §7.2 Relay Multicast Transmission Procedures
Initiate the underlying network specific Push Button Configuration sequence on the IEEE P1905.1 interfaces supporting Push Button Configuration methods.
FIG. 5 describes how an IEEE P1905.1 Device handles an IEEE P1905.1 Push Button Event Notification message (Push Button Event Notification Handling).
The handling of IEEE P1905.1 Management messages in an IEEE P1905.1 Device is a common behaviour (powering up the interfaces and generating a sequential message ID across all message types from the device).
If an ALME receives an IEEE P1905.1 Push Button Notification message, then an IEEE P1905.1 ALME shall:
If an underlying network specific Push Button Configuration sequence is currently being performed of any of the network interface of the device, then ignore the message.
If the message SourceAddress and eventID are a duplicated notification for this given P1905.1 Push Button event, then ignore the message.
The aging of a SourceAddress and eventID pair is P1905.1_PBC_WALK_TIME.
P1905.1_PBC_WALK_TIME should be defined to be longer than the underlying network. No more than a single eventID need to be stored by the P1905.1 device since Push_Button_Event cannot be triggered or handled if an underlying network Push Button Configuration is in progress (cf. 3.2.3 & 3.2.5-1).
3) If message is not ignored, repropagate the received IEEE P1905.1 Push_Button_Event Notification message using §7.3 Relay Multicast Reception Procedures.
4) Initiate the underlying network specific Push Button Configuration sequence on all IEEE P1905.1 interfaces supporting Push Button Configuration methods.
In the following text, several figures with message flow charts are used to explain the described methods. All these message flow charts are based on the network topology shown in FIG. 6 (Network Topology for Message Flow Charts).
From the IEEE P1905.1 draft version 1905_1-11-0067-00-WGDC-proposal-for-cdhn-standard.doc it is further implicitly known that according to FIG. 7 (Push button configuration in IEEE P1905.1) a push button event on one network node device, e.g. a network node device D1, belonging to a heterogeneous home network activates a push button configuration mode on other network node devices D2 . . . D4 belonging also to the heterogeneous home network. The network node devices D1 . . . D4 are part of the existing IEEE P1905.1 network and thus authenticated IEEE P1905.1 devices. The network node device D1 sends a push button notification message PBN to some or all other nodes belonging to the heterogeneous home network. The PBN message may be sent directly or forwarded by an intermediate network node device. It is preferred to send the PBN message by broadcast (relayed multicast) to all network node devices in the heterogeneous network. The PBN message as specified in the current version of the IEEE P1905.1 draft standard contains a TLV type (Type Length Value), a message type, event id fields. A technology-specific Push Button Configuration protocol (PBC protocol) is executed between a new device ND (not yet part of the home network) and a network node device D3. After finishing the technology-specific PBC protocol, the new device ND is part of the heterogeneous home network.
FIG. 8 (Push button configuration in IEEE P1905.1 showing an attacker node AN) shows based on FIG. 7 an example of an attack scenario. An attacker node device AN runs a push button configuration protocol as well, here with the network node device D4. So, after finishing the PBC protocol, the attacker network node device AN is now part of the home network. As different nodes may use even heterogeneous communication technologies, and therefore different technology-specific PBC protocols, the network node device D3 (and the new device ND) may not even detect the second PBC protocol run.
The specific problem of using a push-button configuration in a P1905.1 network comes from the fact that multiple devices (belonging even to different technologies and possibly connected via multiple hops) are activated to accept a new device. So in the current version of the standard, more than one device could register with the P1905.1 network after a single button press. An attacker node may therefore register undetected when an authorized registration of a new device takes place.
Moreover, changes to the existing Push Button Configuration methods of the underlying link communication technologies, e.g. WPS for Wi-Fi, are very difficult to do due to the need for changes in existing specifications as well as for interoperability with the already installed devices.